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10 La presente invention conceme un precede pour le controle d'acces a des 
donn^es manipul^es par des r6ferences dans un systeme infoimatique securise. 

On sait qu'une des caracteristiques principales des systdmes informatiques 
s6curises, qu'ils soient distribues ou non, est le contrSle d'acces aux ressources 
logicielles du systeme, et notamment aux programmes et aux donnees. En 
particulier, lorsque plusjeurs programmes s'ex6cutent simuitanement (ou 
altemativement) dans le systeme, on veut s'assurer que I'execution de I'un 
n'affecte pas I'execution des autres, ni celle du systdme : ils sont isoles. 



15 



20 



Plus generalement, on pent laisser certains programmes interagir entre eux, 
mais uniquement dans le cadre d'une politique stricte de partage contrdle des 
donn6es. On se protege ainsi non seulement de la propagation d'erreurs 
involontaires de programmation, mais aussi et surtout d'actions malveillantes 
(aussi appeles « attaques ») qui vigent a alterer le bon fonctionnement du 
25 systeme et des programmes ou a d6voiler des informations confidentielles. 

Par programme, I'on entend ici non seulement le code executable, c'est-a-dire 
une suite d'instructions, mais aussi le processus (ou tache), c'est-a-dire ie code 
en cours d'execution, avec son environnement specifique constitue des 
donnees qui lui sont propres ainsi que des ressources qui lui sont attributes. 
Par donnees I'on entend aussi bien des valeurs manipulees par un programme 



30 
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que les zones de memoire ou sont rangees des yaleurs- Selon les systemes 
(systemes d'exploitation, environnements d'execution, machines virtuelles. 
etc.)? les donnees appartiennent au programme qui les .a crees ou, plus 
generalement, a un groupe de programmes qui disposent de droits d'acces sur 
5 ces donnees. Ces droits peuvent etre donnes a d'autres programmes pour des 
operations particulieres choisies; de telles donnees sont dites partageables. 

Par exemple, dans le langage « Java Card » (marque deposee de Sun 
Microsystems), les programmes sont organises en « packages » (paquetages) a 

10 rinterieur desquels le partage de donnees (objets et tableaux) est libre. En 
revanche, Tacces a des donnees qui appartiennent k un autre « package » est 
limite pat' deux dispositifs : un mecanisme de demande d'acces et un 
mecanisme de pare- feu (« firewall »). En effet, pour acceder a une donnee 
dont on n'est pas proprietaire, il faut en faire la demande au « package » qui en 

15 est proprietaire, demande qu'il pent accepter ou refuser. Par ailleurs, le pare- 
feu filtre toutes les operations que Ton pent faire sur une donnee, quel que soit 
le moyen par lequel on se Test procuree. En particulier, toute operation de 
lecture ou d'ecriture sur un objet d'un autre « package » est interdite, sauf pour 
appeler une methode (routine de programme) explicitement declaree par ce 

20 « package » comme partageable. II existe egalement des objets du systeme 
(c'est-a-dire de Penvironnement d'execution «Java Card Runtime 
Environment », ou JCRE) qui sont accessibles (sans droits d'acces 
particuliers) par tout programme. 

25 Les donnees d'un programme, et en patticulier les donnees complexes 
(structures, objets, tableaux, etc.) sont generalement identifiees par ime 
reference. C'est par Tintermediaire d'une reference que la donnee associee, 
ainsi que les composants de cette donnee (champs de structures et d' objets, 
elements de tableaux, methodes, etc.), peuvent etre manipules, c'est-a-dire lus, 

30 ecrits, appeles. La reference elle-meme pent etre memorisee, re9ue et 
transmise. 
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Une reference est souvent un pointeur ou un « handle ». Un pointeur est 
I'adi-esse ot se trouve rangee une dorniee dans la m^moire. Un « handle » est 
un index dans une table de pointeurs (ou plus generalement dans une table de 
references). Les valeurs des pointeurs et « handles » comportent aussi pai-fois 
des bits specifiques qui donnent des informations sur la donnee (par exemple 
sur Ja zone memoire referencee ou sur I'information s'y trouvant) ou, dans le 
cas de « handles », sur la table associ^e. 

Trois attributs majeurs concement la « correction » des references : 

- Une reference pent 6ti-e valide ou invalide. Une reference valide est 
une reference associee effectivement a une donnee d'un programme. 
Une reference invalide est une valeur stockee ou exploitee en tant 
que reference mais qui n'est pas associee a une donnee. Par exemple, 
dans le langage C, un pointeiir vers une structure de donnee est 
valide ; en revanche, un pointeur vers Fei^ment d'un tableau a 
rindice -I est invalide. La validite d'mie reference est intrinseque ; 
elle ne depend pas I'agent (programme, processus, tache, etc.) qui la 
manipule. 

- Une reference peut aussi 8tre licite ou illicite, pour un agent donne 
du systdme. Une reference licite est une reference qui a ete obtenue 
par des moyens licites. Une reference illicite est une reference n'a 
pas ete obtenue par des moyens licites. La definition effective de ce 
qu'est une reference licite ou illicite depend du systeme, du langage 
de programmation et eventuellement du contexte. Par exemple, en 
langage C, I'axithmetique de pointeur (fabrication d'un pointeur par 
addition d'un pointeur et d'un entier) est licite ; elle est revanche 
illicite en « Java ». Une reference n'est pas intrinsequement licite ou 
illicite : c'est une propriete specifique a un agent, qui depend de la 
maniere dont la reference a ete obtenue par cet agent. 



1 er depot 



-4- 

- Une reference peut egalement etre « dereferen9able » ou 
« indereferenfable » par un agent donne. Une reference 
dereferen9able par un agent est une reference vers une donn6e pour 
laquelle T agent a des droits d'acces. Une reference indereferen9able 
5 par un agent est une reference vers une donnee pour laquelle T agent 

n'a pas de droits d'acces. Par exemple, en « Java Card une applet 
qui detient une reference vers un objet peut acceder a un champ de 
cet objet (ou. element, dans le cas ou Tobjet est un tableau) a la 
condition que Tobjet appartienne au meme package (paquetage) que 

10 cette applet. En revanche, si T objet appartient a un autre package 

(different egalement du JCRE), toute tentative d'acces est stoppee 
par un mecanisme de pare-feu et resulte en une levee d' exception (de 
la classe « SecurityException »), Une reference n'est done pas 
intrinsequement dereferen9able ou indereferen9able : c'est une 

15 propriete specifique a Tagent qui detient la r6ference et aux droits 

d'accds qu'il d6tient ou non sur la donnee referencee. 

II faut noter que ce sont la trois notions independantes. 

20 Ainsi, une reference peut etre invalide et licite ; c'est par exemple le cas dans 
un langage comme C quand on accede aux elements d'un tableau par 
arithmetique de pointeur et lorsque Ton depasse les limites du tableau, Une 
reference peut aussi etre valide et illicite : c'est par exemple le cas de 
references fabriquees a partir de references connues, dans le cadre d'une 

25 attaque, pour acceder a des donnees protegees auxquelles on ne devrait pas 
avoir acces, Enfm, une reference peut egalement etre a la fois invalide et 
illicite ; c'est par exemple le cas de references fabriquees dans le cadre d'une 
attaque pour ecraser les donnees du programme par balayage systematique et 
« aveugle » de la memoire» 

30 
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Par ailleurs, ime reference peut etre dereferenpable ou non, qu'elle soit valide 
ou invalide, licite ou illicite. Ainsi, I'acces a une zone meraoire protegee, que 
la reference soit valide ou non, peut 6tre contrdle par des droits. D'autre part, 
on peut obtenir pai- des moyens iUicites une r6f^rence vers une donnee sur 
laquelle on a des droits d'acc^s ; on peut par exemple la fabriquer de toute 
pi^ce au lieu de la demander'au systdme. Inversement, on peut obtenir par des 
moyens iicites une reference vers une donnee sur laquelle on n'a pas des droits 
d'acces, par exemple pour transmettre cette reference h un autre agent qui, lui, 
a les droits d'acces appropries. 

L'invention a plus particulierement pour objet le controle des references 
iliicites, les questions de validite et de « dereferen9abilite » pouvant Stre 
traitees par ailleurs a I'aide de mecanismes qui sontpropres k ces notions. 

De mani^re g6n6rale, I'acces a une donnee structuree se fait en deux temps. II 
faut tout d'abord obtenir une reference sur la donnee. On peut ensuite operer 
sur la donnee via sa reference, c'est-a-dire lire ou ecrire les composants 
(champs d'objet ou de structure, elements de tableau, etc.) de la donn6e 
referencee, ou appeler une de ses routines. 

II y a trois moyens principaux d'obtenir des r6f6rences : 

- Un moyen licite de se procurer une reference est de I'obtenir du 
systeme ou d'un autre programme. Par exemple, en « Java » et en 
«Java Card», les references sont cr6ees par le systeme lors de 
I'allocation de nouvelles zones de donnees en m6moire. Ces 
r6f6rences peuvent etre fournies et obtenues par un des moyens 
suivants: lecture et ecriture de champs publics d'objets ou de 
classes, arguments d'appels et valeur de retour de methodes, levee et 
rattrapage d'exceptions. En « Java Card », I'acces a un champ public 
d'un objet appartenant h un autre « package » est toutefois interdit 
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par le pare-feu. Par ailleurs, une reference a una doraiee partageable 
appartenaiit an systeme ou a un autre « package » pent 
demandee aupres du systeme, 

- On pent aussi fabriquer une reference a partir d'une autre. Par 
5 exemple, dans le langage C, additioimer ou soustraire un entier a un 

pointeur fabrique un nouveau pointeur, Le pointeur resultant est 
licite car rarithmetique de pointeurs est licite. Mais il est valide ou 
non suivant la donnee referencee par le pointeur initial (pointeur a 
rinterieur d'un tableau ou d'une structure). Dans d'autres langages 
10 que C, le pointeur resultant pent ne pas 6tre licite. C'est le cas pour 

les langages « Java » et « Java Card », que ce soit au niveau du code 
source ou du code objet destine. a Fexecution dans une machine 
virtuelle. 

- Enfin, on pent aussi fabriquer une reference de toute piece. Un 
15 simple entier pent ainsi etre considere comme un pointeur ou un 

«haQdle» apres attribution d'un type reference. La reference 
resultante peut etre valide ou invalide. Elle est en revanche 
generalement consideree illicite, comme par exemple en « Java » et 
«Java Card». Une telle reference peut toutefois etre consideree 
20 comme licite dans des contextes et pour des langages particuliers. 

C'est le cas en langage C quand on accede a des ports d'entrde-sortie 
installes a des adresses memoires determinees. 



Aux deux temps de Faeces a la donnee (obtenir une reference, puis operer sur 
25 la donnee associee via la reference) correspondent deux mesures couramment 
employees pour le controle d'acces : 

« D'une partj il faut empecher la contrefa9on de references. Autrement 
dit, un programme ne doit pas pouvoir fabriquer une reference et 
pretendre Tavoir obtenue par des moyens licites. Comme indique ci- 
30 dessus, le sens de « moyen licite » varie selon les systemes, les 

contextes, et les langages de programmation utilises. Pai' exemple, a 
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la difference du langage C qui permet d'effectuer des operations 
arithmetiques sur les pointeurs, les langages «Java» et «Java 
Card » ont un syst^me de typage des donn^es qui ne permet pas 
d'effectuer des operations sur des ref6rences ni d'en fabriquer de 
nouvelles de toute piece. Les seules references dont un progi-amme 
peut legitimement disposer en « Java » ou « Java Card » sont celles 
que lui a fourai le systeme (y compris la machine virtuelle) ou un 
autre programme, et qu'il a eventuellement m^morisees. La 
contrefa9on de references est done fonctionnellement impossible 
avec des programmes bien types. La contrefapon est toutefois 
possible au niveau d'une machine virtuelle « Java » ou « Java Card » 
si elle n'effectue pas de verification de type, qu'elle soit statique ou 
dynamique (voir ci-dessous). M^me en cas de verification, il est 
toujours possible de creer des references illicites par injection de 
fautes au niveau materiel (bombardement electronique, variations 
dans I'alimentation 61ectrique, etc.), par exemple dans le cadre d'une 
attaque contre une carte a puce. 

D'autre part, le systeme doit fiitrer toute operation sur les references. 
Autrement dit, le programme ne doit pas pouvoir effectuer 
directement une operation de lecture ou d'ecriture sur des donnees 
referencees ; ii doit passer par I'intermediaire du systdme, qui peut 
accepter ou refuser Toperation, en fonction du programme 
demandeur et des donnees referencees (notamment de leur 
proprietaire). Par exemple, a la difference des instructions du 
langage machine, qui permettent un acces direct et imm6diat k toute 
donnee referenc6e, les instructions de la machine virtuelle «Java 
Card » (JCVM) verifient syst6matiquement des conditions de I'acces 
aux donnees avant de I'accepter ou de le refuser ; c'est le mecanisme 
de pare-feu du JCRE. Ce controle inclut egalement I'acces aux 
elements d'un tableau : le systeme verifie que I'indice des elements 
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auxquels on accede reste dans les limites licites, etant donnee la 
taille du tableau. 

Aucune de ces deux mesures, prise individuellement, ne sufSt en general a 
5 securiser un systeme ; la securite repose sur leur combinaison. En fait, les 
types de protection offerts par chacune de ces deux mesures se recouvrent 
partiellement et se completent : 

- Ainsi, empecher la contrefa9on de references garantit qu*un 
programme ne manipule que des references licites. Cependant, 
10 Tacces k toutes les donn6es coirespondant a des references licites 

n'est pas pour autant autorise ; la presence additionnelle d'un pare- 
feu permet de restreindre les operations qu'un progi'amme pent 
effectuer sur des references, qu'elles aient ete obtenues par des 
moyens licites ou non, 
15 - Toutefois, un pare- feu qui controle toutes les operations sur les 

references ne suffit pas a garantir la securite d'une politique d'acces 
aux donnees : il peut etre trompe par des references contrefaites, 
C'est par exemple possible si Timplementation represente les 
references par des pointeurs directs vers des blocs memoire. En effet, 
20 dans ce modele, les descripteurs de donnees (c'est-a-dire les 

informations de proprietaire, de classe, de type et de taille de tableau, 
utilisees lors de la verijBication du droit d'acces) sont stockes en 
memoire a des deplacements fixes pai' rapport aux pointeurs. II suffit 
. a un programme malintentionne de contrefaire un pointeur au milieu 
25 d'un bloc de donnees, par exemple au milieu d'un tableau d'octets 

convenablement rempli, pour briser Tintegrite de la memoire : une 
telle attaque permet en effet de faire croire au systeme que la donnee 
associee au pointeur non seulement appartient au programm.e et est 
done accessible, mais aussi que la zone memoire de cette donnee est 
30 d'une etendue arbiti^airement grande, ce qui permet de lire ou d'ecrire 

une cellule memoire quelconque. Ainsi, le controle des operations 
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sur les references n'interdit pas la fabrication et I'usage d'une 
reference qui n'a pas ete obtenue par des moyens licites ; un acces 
illicite a une donnee est done possible maJgre le pare-feu. 

Le probBme de I'interdiction de la contrefafon de references est g6neralement 
r6solu de deux manieres : par une verification statique reposant sur une 
analyse de programme ou par une verification dynamique des types de 
valeurs : 

- La verification statique par analyse de programme contr61e 
statiquement (une fois pour toute, avant toute execution) que le 
programme ne peut pas fabriquer lui-meme de references sur des 
donnees. Autrement dit, une reference ne peut pas 6tre le resultat 
d'un calcul arbitraire du programme. Dans le cas d'un langage 
comme « Java» ou «Java Card », cette verification de type peut 
s'effectuer aussi bien au niveau d'un programme source 
(typiquement, a la compilation) qu'au niveau des programmes objets 
executables par une machine viituelle (typiquement, lors du 
chargement du programme dans le systeme ou avant son execution), 
a I'aide d'un verificateur de code octet (« bytecode verifier »). 
- La verification dynamique des types de valeur fait en sorte que les 
valeurs manipulees par le programme soient marquees par leur type 
(entier, reference, etc.). On verifie alors dynamiquement (lors de 
I'execution) que seules les valeurs marquees comme etant 
effectivement des references sont utilisees dans les operations qui 
portent sur des references. Le marquage n'est pas necessairement 
associe explicitement aux valeurs ; il peut porter sur les zones de 
stockage des valeurs et etre limite a uniquement certaines zones. Par 
exemple, dans le cas de la machine virtuelle « Java » ou « Java 
Card », il est suffisant de typer dynamiquement la pile d'operandes et 
les variables locales. En revanche, les valeurs stockees dans des 
tableaux, dans des champs statiques ou dans des champs d'instances 
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n^ont pas besoin d'etre explicitement marquees par leur type, car ce 
type peut etre retfouve a partir d'autres informations (classe de 
Tobjet, type du tableau) disponibles par ailleurs. Cette approche, dite 
« pile typee », empeche la contrefa9on de pointeur car elle permet a 
5 la machine virtuelle de detecter et d'empScher toutes les tentatives de 

conversion d'un entier en reference, ainsi que les operations 
arithmetiques sur les references. Une valeur « Java » ou « Java 
Card » qui a le type reference est ainsi toujours une reference vers un 
bloc memoire bien forme du systeme, contenant des informations 
10 correctes de propri^tairCj de classe, et de taille. 



Ces solutions ne sont pas redondantes ou exclusives ; elles correspondent a des 
besoins ou a des moyens differents : 

- Ainsi, la verification statique par analyse de programme peut etre 
15 difficile a metti-e en oeuvre dans des petits systemes embarques tels 

que les cartes a puce, qui disposent de peu de lUjemoire et dont la 
Vitesse d'execution est faible. Cependant, elle a Tavantage de signaler 
un probleme le plus t6t possible, Un programme peut par exemple 
etre rejete des son chargement dans le systeme. (La verification peut 
20 aussi avoir lieu en dehors du systeme d'execution et une signature 

infalsifiable etre apposee sur les programmes valides.) 

- Pour sa part, la verification dynamique des types de valeur a 
rinconvenient de consommer un peu de memoire (marque de type 
ajoutee aux valeurs ou a certaines zones de stockage) et surtout 

25 d'etre couteuse en temps d' execution (affectation et conti'ole des 

marques). Cependant, elle a Tavantage d'etre robuste : si un 
programme a reussi a etre charge dans le systeme, m6me par des 
moyens detoumes, il ne pourra de toute fa9on pas effectuer 
d'operations illicites. C'est aussi une garantie supplementaire contre 

30 des attaques materielles (par opposition aux attaques logicielles). Par 

exemple, meme confinee dans une enceinte securisee, comme celle 
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d'une carte a puce, rexecution des programmes peut neanmoins §tre 
perturbee en agissant sur le materiel (variations de I'alimentation 
electrique, bombardement par des rayonnements, destructions de 
portes logiques, etc.). La verification dynamique est alors un moyen 
5 de contrdler regulierement, k chaque operation sensible, que la 

politique de controle d'acces est bien respectee. 

Ces solutions, mises en ceuvre partielleraent ou en totalite, peuvent 6tre 
combin6es afm de trouver les meilleurs compromis d'efficacit^ ou foumir la 
10 meilleure garantie possible. 

Une autre approche, qui ne resout que partiellement le probleme lie a la 
contrefa9on de references, consiste a verifier que toute valeur utilisee en tant 
que reference est effectivement une reference connue du systeme. Cette 
15 verification dynamique de la validity des rdf^rences n'interdit pas la fabrication 
de references. Cependant, elle interdit I'usage de ref6rences qui en fait n'en 
sont pas. En d'autres termes, seules les valeurs qui sont effectivement des 
references peuvent etre utilisees en tant que telles par le programme. 

20 La mise en ceuvre d'une verification dynamique de la validite des r6f6rences 
depend fortement de la maniere de representer et de gerer les references dans 
le systdme. Par exemple, un gestionnaire de memoire, aupres de qui I'on peut 
demander la cr6ation d'une nouvelle zone de donnees ou bien sa liberation, sait 
exactement quelles references ont ete creees. II est done possible de savoir si 
un entier correspond ou non a une reference valide existante. Dans le cas ou 
les ref6rences sont representees par des pointeurs, cette operation est toutefois 
coOteuse car elle peut n6cessiter un large parcours des structures de donnees 
du gestionnaire de memoire. En revanche, si les references sont representees 
par des « handles », la verification. est bien plus facile et surtout plus rapide : il 
suffit de verifier que I'entier est inferieur ou egal k I'indice maximum de la 



25 



30 
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table de « handles » du gestionnaire de memoire, et que Tentree associee dans 
la table ne correspond pas a des donnees qui ont ete liberees. 

Au m6me titre que les deux verifications decrites ci-dessus (verification 
5 statique par analyse de programme et verification dynamique des types de 
valeur), la verification dynamique de la validite des references constitue une 
protection centre les attaques qui fabriquent des pointeurs vers de faux 
descripteurs de donnees (attaque decrite ci-dessus). En effet^, ces pointeurs 
contrefaits ne sont pas reconnus par le systeme comme des references valides 

10 existantes et les operations d'acces sont d*emblee rejetees. Toutefois, ce type 
de verification ne garantit pas que le programme s'est procure par des moyens 
licites toutes les references qu'il utilise. Un agent pent notamment fabriquer et 
utiliser une reference valide et dereferen9able (reference vers une donnee sur 
laquelle il a des droits d'acces, par exemple une donnee partageable 

15 appartenant a im autre programme) sans qu*elle ait toutefois ete obtenue par 
des moyens licites. 

L' invention a done plus parti culierement pour but de resoudre les problemes 
precedemment evoques, 

20 

Elle propose a cet effet une forme de verification dynamique qui porte sur la 
contrefagon de references et qui, d'une* certaine maniere, complete la 
verification dynamique de la validite des references pour couvrir les cas 
d'utilisation de references illicites. 

25 

Conformement a T invention, cette verification dynamique des references 
licites consiste, au cours de Texecution d^un programme, k : 

- memoriser I'ensemble des references a des domiees qu'obtient le 
programme par des moyens licites, 
30 - verifier, avant toute operation que Ton veut interdire si elle porte sur 

une valeur qui n'est pas une reference licite, que cette valeur est 
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parmi les references licites que Ton a memorisees pour ce 
programme. 



Dans ce procede, les references pourront consister en des pointeurs ou des 
5 « handles ». 



Les moyens licites pour un programme d'obtenir des valeurs de reference 
pourront comprendre au moins I'une des operations suivantes : 



10 



15 



- la lecture d'une variable ou d'une donnee appartenant au systeme ou 
a un autre programme, 

- l'6criture dans une variable ou donnee dudit programme par le 
systeme ou par un autre programme, 

- la reception d'arguments a I'appel d'une routine dudit programme par 
le systeme ou par un autre programme, 

- rexploitation de la valeur de retour de I'appel par ledit programme 
d'une routine appartenant au systeme ou a un autre programme, 

- le rattrapage par ledit programme d'une exception levee durant 
I'execution d'une routine appartenant au systeme ou ^ un autre 

20 programme, 

- la reception par ledit programme d'une interruption ou d'un signal 
value. 

Le systeme pourra disposer d'un mecanisme pour determiner si une valeur 
25 domaee est une reference valide, les references licites memoris6es etant 
restreintes aux seules references sur des donnees consid^r^es comme sensibles 
par le systeme. 



30 



Les susdites verifications poun-ont consister a controler que les valeurs sont 
parmi les references licites sensibles que I'on a memorisees pour ce 
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programme ou bien sont des references determinees comme valides et portant 
sur des donnees qui ne sont pas sensibles. 

Avantageusement, le systeme poiirra disposer d'un mecanisme (dit de pare- 
feu) qui interdit a certains programmes certaines operations sur certaines 
donnees referencees. Dans ce cas, les donnees considerees comme sensibles 
pour le systeme pounront consister en des donnees pour lesquelles les 
operations ne sont pas interdites par le pare-feu. 

De meme, le pare-feu pourra interdire a un progranmie certaines operations 
sur des donnees appartenant a d'autres programmes ou au systeme, excepte sur 
celles declarees comme partageables. 

Le systeme d' execution de programmes mis en oeuvre par le proc6de selon 
rinvention pourra Stre base sur une machine virtuelle « Java Card » et dans ce 
cas : 

- le programme execute par le systeme pourra etre constitue par 
r ensemble du code qui se trouve dans un « package » « Java Card », 

- le mecanisme de pare-feu pourra consister en celui du « Java Runtime 
Environment » (JCRE), 

- les donnees declarees comme partageables (et done sensibles) pounront 
consister en les objets qui sont des instances de classes qui 
implementent T interface « javacard. framework. Shareable » lorsque 
ledit « package » appelle une methode d'un autre « package » ou du 
systeme (y compris la methode « getAppletShareablelnterfaceObject » 
du package « javacard. JSrameworkJCSystem »), 

- la lectxire d'un champ statique public de type 
« javacard.fi'amework.Shareable » dans un autre « package » ou dans le 
systeme. 
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20 



- le rattrapage d'un objet instance d'une classe provenant (heritant) de 
«java.lang.Throwable» et impl^mentant « javacard.framework. 
Shareable ». 

Dans le proced6 pr6c6demment decrit, I'enseinble des references licites (ou 
licites sensibles) memorisees pouiTa atre represente par une table. 



II pourra 8tre vide, grSce k un ramasse-miettes, des references devenues 
inactives (c'est-i-dire correspondant a des donnees effac^es du programme ou 
10 inutilisables pour un acces fiitm- dans la suite de I'execution), ce ramasse- 
miettes pouvant etre conservatif. 

Les references pourront etre representees dans le systeme par des « handles » 
et des tables de pointeurs (ou de references), certaines de ces tables etant 
15 6ventuellement reservees aux references licites (ou licites sensibles). 

Les ensembles de references licites (ou licites sensibles) memorisees pourront 
atre representes par des vecteurs (ou matrices) de bits associds h certaines des 
tables de pointeurs (ou de references) ot un bit, k un index donne, represente 
la presence ou I'absence de la reference correspondante dans lesdits 
ensembles. 



Les vecteurs de bits pouiTont etre eventuellement creux et representes a I'aide 
d'une sequence d'indices ou de longueurs correspondant aux etendues de bits 
25 positionnes de la meme manidre (soit a 1 , soit k 0). 

De m6me que la verification dynamique de la validite des references, le 
mecanisme mis en osuvre par le precede selon Finvention n'interdit pas la 
contrefapon de references. Cependant, il interdit Pacces a des donnees via des 
30 references qui ne peuvent pas etre obtenues par des moyens licites. Or c'est ce 
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controle qui seul importe ; que la reference ait ete fabriquee de toute piece en 
pratique importe peu tant qu^elle. est licite. 

Par exemple, si le programme construit un entier et tente de Tutiliser comme 
une reference, soit cat entier ne correspond pas a une reference presente dans 
Tensemble des references licites memorisees pour ce programme et P operation 
est rejetee, soit cet entier correspond a une reference deja presente dans 
Tensemble des references licites memorisees pour ce programme et ne permet 
done de faire que des acc^s licites. L^attaque d'un programme malveillant 
cherchant a fabriquer une reference vers une donnee partageable deviant ainsi 
ininteressante puisque le programme ne pourra acceder a cette donnee que s'il 
avait de toute fa9on pu obtenir cette meme reference auparavant, par des 
moyens licites. 

II est possible de perfectionner ce mecanisme de plusieurs manieres : 

- d'une part, on pent limiter les references a memoriser a celles qui 
important pour la politique de securite du systeme et limiter le 
controle aux seules operations que Ton veut voir interdites quand 
elles portent sur des references illicites ; 

- d'autre part, suivant le mode de representation des references, on 
pent mettre en ceuvre des implementations plus ou moins efficaces 
des ensembles de references licites memorisees. 

Des perfectionnements, dont Tobjectif est de consommer moins d'espace 
memoire et moins de temps d'execution, sont combinables et seront decrits ci- 
apres a titre d'exemples non limitatifs. 

La verification dynamique des references licites sensibles : 
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L'acces aux domiees est parfois cloisonne au sein d'un m6me programme. Par 
example, en « Java » comme en « Java Card », certains champs d'une classe 
peuvent 6tre declares pnv6s et ainsi n'^tre accessibles qu'a partir des mdthodes 
de cette classe. Toutefois, ce contrSle d'accessibilit^ correspond souvent plus k 
des motivations de genie logiciel qu'^ un souci de securite. Ce qui importe 
veritablement en «Java Card» est le cloisonnement entre ies donnees de 
programmes differents car, en quelque sorte, les programmes « ne se font pas 
confiance entre eux ». En revanche, k I'interieur d'un mBme programme, il 
importe peu de restreindre les acc6s possibles. Par exemple, mSme si une 
reference vers une donnee du programme est stockee dans un champ priv6, et 
si ce m6me programme fabrique de maniere quelconque un exemplaire de 
cette reference sans lire ce meme champ prive et I'utilise pour acceder a la 
donnee, la securite du programme et de ses donnees n'est pas mise en danger. 

Cette remarque permet de defmur un premier perfectionnement du mecanisme 
de verification dynamique des r6f6rences licites en restreignant les references 
memorisees et controlees. Ce perfectionnement est defmi de la maniere 
suivante : 

- d'une part, on ne memorise au cours de I'execution que I'ensemble 
des references a des donnees sensibles qu'obtient un programme par 
des moyens licites. C'est le contexte ou le type de systeme qui 
determine quelles sont les donnees que Ton peut considerer comme 
« sensibles ». Par exemple, dans le cas de « Java Card », on peut ne 
considerer comme sensibles pour un programme que les donnees qui 
appartiennent aux autres programmes. On peut exclure des donnees 
consid6rees comme sensibles les donn6es publiques du systeme : 
tableaux globaux (« global arrays ») et objets points d'entree du 
JCRE (« JCRE Entry Point Objects »). En effet, bien qu'on ne puisse 
obtenir des references vers ces donnees que dans des circonstances 
particulieres (par exemple, retour d'appel de routine), I'acces a ces 
donnees est ouvert a tons. En pratique, les donnees sensibles peuvent 
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meme se reduire aux seules donnees explicdtement declarees comme 
partageables, c'est-a-dire aux objets qui sont des instances de classes 
qui implementent Tinterface «javacard.framework. Shareable », car 
les autres donnees sont de toute fa9on protegees par le mecanisme de 
pare-feu de la JCVM. Dans ce dernier cas, on memorise dans 
Tensemble des references licites sensibles d^un « package » toutes les 
references qui apparaissent dans les cas suivants : passage 
d*arguments de type « Shareable » lorsqu'une methode du 
« package » est appelee, valeur de retour de type « Shareable » 
lorsque le « package » appelle une methode d'un autre « package » 
ou du systeme (y compris la valeur de retour de la methode 
« getAppletShareablelnterfaceObject » du package 

« javacard.frameworkJCSystem »), lecture d^un champ statique de 
type « Shareable » dans un autre « package », et rattrapage d'une 
exception de type « Shareable » ; 

d^autre part, on verifie, avant toute operation que Ton veut interdire si 
elle porte sur des valeurs qui ne sont pas des references licites, que la 
valeur est parmi les references licites sensibles que Ton a 
memoris6es pour ce programme ou bien est une reference valide sur 
une donnee qui n^est pas sensible, II faut noter qu*il est indispensable 
de disposer egalement d'un mecanisme de verification de la validite 
des references (voir ci-dessus) afin de se premunir conti'e des 
attaques par contrefa9on d'une reference vers un faux descripteur de 
donnees. Dans le cas de la JCVM, si Ton ne considere comme 
sensible que les objets partageables, il suffit que Tinstruction 
« invokeinterface » verifie, lorsque qu'elle est appliqu^e k une 
reference vers un objet appartenant k un autre « package », que cette 
refei'ence appartient bien a I'ensemble des references licites sensibles 
associe au « package » appelant. 
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Cette verification dynamique des references licites sensibles a I'avantage de 
consommer moins d'espace memoire, puisqu'on memorise moins de 
references, et moins de temps d'ex6cution, puisqu'on v6rifie moins 
d'opdrations et que le test d'appartenance a I'ensemble des r6ferences licites est 
5 plus rapide du fait de sa plus petite taille. 

Representation de I'ensemble des references licites : 

Par ailleurs, les petits systemes embarques tels que les cartes a puce disposent 
1 0 de ti-es peu de memoire. 11 est done important sur de tels systdmes de pouvoir 
repr6senter I'ensemble des references licites (ou licites sensibles) d'un 
programme de mani^re compacte tout en permettant une verification 
dynamique rapide. 



15 



20 



25 



La methode la plus directe pour representer I'ensemble des references licites 
(ou licites sensibles) d'un programme est d'utiliser une table. Lors de 
introduction dans le programme d'une reference par un moyen licite, on 
I'ajoute dans la table si elle n'y est pas deja presente. La verification qu'une 
reference est licite se fait par examen successif des enti-ees dans la table. 

D'autres manieres standards en algorithmique pour repr6senter des ensembles 
peuvent aussi 6tre employees : listes, arbres, etc. Certaines representations des 
ensembles permettent notamment d'optimiser les operations d'ajout, de 
suppression et de test de presence d'un element dans un ensemble lorsqu'on 
connait a -I'avance le nombre maximum (ou maximum probable) d'elements. 
On peut en effet aiors dimensionner I'ensemble selon ce nombre maximum et 
faire des acces plus ou moins directs aux elements. 

Nettoyage de I'ensemble des references licites : 



30 



1 er depot 

-20- 

D' autre part, il faut veiller a la coherence des references licites (ou licites 
sensibles) memorisees en cas de suppression de donnees* 

En effetj en cours d'execution, des donnees devenues inutiles ou inaccessibles 
5 peuvent etre suppriraees de la memoire du systeme ou d'un programme. Une 
donnee devient inaccessible des lors que le programme ne contient plus de 
r6ference active sur cette donnee, c'est-a-dire encore susceptible d'etre utilisee 
par le programme dans la suite de son execution. De telles donnees peuvent 
6tre effacees explicitement, par Tappel k une routine de liberation de memoire, 
10 ou automatiquement, par un ramasse-miettes (« garbage collector »). 

Si une reference devient inactive dans un programme, Tensemble des 
references licites (ou licites sensibles) memorisees reste compatible avec la 
securite du systeme : le programme est de toute fafon libre d*utiliser ou non 
15 les references dont il dispose, et Ton pent controler que toutes celles qu*il 
utilise sont bien licites, Un tel ensemble pent toiitefois Btre nettoye des 
references inactives, afin de reduire son encombrement en memoire. Ce 
nettoyage devient meme imperatif si Fallocateur de donnees pent creer une 
nouvelle donnee associee a une r6ference dont la donn6e a ete supprimee. 

20 

Le nettoyage de Tensemble des references licites (ou licites sensibles) peut 6tre 
effectue automatiquement, par un ramasse-miettes, II doit pour cela parcourir 
toutes les valeurs presentes dans le programme en cours d'execution afin de 
deteraiiner les references encore actives. Toutes les references rencontrees lors 
25 de ce parcours sont marquees comme « encore en service » dans Tensemble 
des references licites du programme. A la fin de ce parcours, toutes les entrees 
non marqu6es peuvent . etre liberees ; elles correspondent a des donnees 
auxquelles le programme a pu acceder dans le passe, mais sur lesquelles il n'a 
pas garde de reference (ou pas de reference utilisable). 

30 
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Dans le cas o*u des donnees peuvent ainsi 6tre effacees, il n*est pas necessaire 
de dimensionner Tensemble des references licites selon le nombre de donn6es 
refiSrencees dans le s3^steme : on pent le sons-dimensionner et le debarrasser 
regnlierenient, par exemple lorsque Tensemble est plein, des elements qui ne 
5 sont plus utiles. Ainsi, il suffit de dimensionner I'ensemble des references 
licites d'un programme an nombre de references simultanement actives lors de 
son execution, nombre qui est plus petit que le nombre de donnees referenc€es 
dans le systeme. 

10 Par ailleurs, dans le cas ou Ton ne sait pas decider avec certitude si une valeur 
represente ou non une reference^ ce qui est le cas dans un systeme d'execution 
(y compris une machine virtuelle) qui ne consei^ve pas toutes les infomiations 
de type^^ on peut avoir recours a un ramasse-miettes dit « conservatif », Avec 
un tel ramasse-miettes, toute valeur susceptible d^etre une reference (par 

15 exemple un entier) est consideree comme telle par securite. Ce ramasse- 
miettes est dit conservatif car les valeurs prises, a tort pour des references' 
empSchent le nettoyage de ces references ; en revanche, on est sur qu'aucune 
reference ne peut etre supprimee tant qu'elle est encore active. 

20 Representation des references licites par filtrage des tables de « handles » : 

Eniin, lorsque les references sont representees par des « handles », auxquels 
correspondent des index associes a une ou plusieurs tables de pointeurs (ou de 

references) gerees par le systeme, rensemble des references licites (ou licites 
25 sensibles) d'un programme peut etre represente de maniere plus compacte. 

On peut employer pour cela des vecteurs de bits de m6me taille que les tables 
de pointeurs. Ces vecteurs sont interpretes comme des filtres sur les tables de 
pointeurs (ou de references) pour indiquer les references consid6rees comme 
30 presentes dans I'ensemble ; un bit leve (egal a 1) ou non (egal a 0) a un index 
donne indique si la reference correspondante doit etre consideree ou non dans 
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i' ensemble des references licites (ou licites sensibles) du programme. L'ajout^ 
la suppression et le test de presence d^im element dans Tensemble est 
extrSmement rapide puisqu'il n'y a qu'nn bit a positionner ou tester. En 
attribuant des numeros aux programmes^ on peut aussi regrouper ces vecteurs 
5 de bits en une matrice de bits dont une des coordonnees est indexee par le 
numero du programme. 

S'il y a beaucoup de references dans le systeme et si tres peu sont a considerer 
comme licites (ou licites sensibles) pour chacun des programmes, cette 
10 matrice de bits peut finalement s'averer moins compacte qu'une representation 
par simple table de references explicites. Dans ce cas, on peut essayer 
d' employer une representation sous forme de vecteur creux (ou de matrice 
creuse), par exemple une sequence d'indices ou de longueurs correspondant 
aux etendues de bits positionnes de la meme mani^re (soit k 1, soit a 0). 

15 

On peut aussi exploiter des tables differentes pour memoriser d'une part les 

« handles » qui sont des references licites (ou licites sensibles) et d'autres part 
les autres references. Les vecteurs de bits deviennent ainsi beaucoup moins 
longs et beaucoup plus denses. 
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Revendications 

1. Proc6de de contrdle d'acces a des doiin^es manipulees par references 
daris un systeme d'execution de programmes (y compris processus et taches), 
caracteris6 en ce que, lors de I'execution d'un programme, il comprend les • 

etapes suivantes : 

- la memorisation par ie systeme de I'ensemble des r6tences qu'obtient le 
programme par des moyens consid6r6s comme licites ; 

- avant toute operation que I'on veut interdire si elle porte sur des valeurs 
qui ne sont pas des references licites, la verification par le systeme que ces 
valeurs sont parmi les references licites que I'on a memorisees pour ce • 
programme, et I'acceptation ou le rejet de I'operation en consequence. 

2. Precede selon la revendication 1, 

caracterise en ce que les references sont des pointeurs et/ou des « handles ». 

3 . Precede selon la revendication 1 , 

caracterise en ce que les moyens licites .pour un programme d'obtenir^ des 
valeurs references comprennent au moins I'une des operations suivantes : ' 

- la lecture d'une variable ou d'une donn6e appartenant au systeme ou k un 
autre programme, 

- r6criture dans une variable ou donnee dudit programme par le systeme ou 
par un autre programme, 

- la reception d'arguraents k I'appel d'une routine dudit programme par le 
systeme ou par un autre programme, 

- I'exploitation de la valeur de retour de I'appel par ledit programme d'une 
routine appartenant au systfeme ou ^ un autre programme, 

■ le rattrapage par ledit programme d'une exception levee durant I'execution 

d'une routine appartenaat au systeme ou a un autre programme, 
• la reception par ledit programme d'une interruption ou d'un signal value. 
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4. Precede selon la revendication 1 ^ 
caracterise en ce que : 

le systeme comprend un mecanisme qui deteraiine si une valeur doimee 
est une reference valide, et/ou 

les references licites memorisees sont restreintes aux seules references sur 
des donnees considerees comme sensibles pour le systeme, et/ou 
lesdites verifications controlent que les valeurs sont parmi les references 
licites sensibles que Ton a memorisees pour ce programme ou bien sont 
des references determinees comme valides et portant sur des donnees qui 
ne sont pas sensibles, 

5. Procede selon la revendication 4, 

caracterise en ce que le systeme comprend un pare-feu qui interdit a certains 
programmes certaines operations sur certaines donnees referencees, les 
donnees consider6es comme sensibles pour le systeme 6tant celles pour 
lesquelles les operations ne sont pas interdites par le pare-feu. 

6. Procede selon la revendication 5^ 

caracterise en ce que le pare-feu interdit a un programme certaines operations 
sxxr des donnees appartenant a d^autres programmes^ excepte sur celles 
declarees comme partageables. 

7. Procede selon la revendication 6, 

cai-acterise en ce que le systeme est base sur une machine virtuelle « Java 
Card » et en ce que : 

un programme est constitue par Tensemble du code qui se trouve dans un 

« package Java Card » ; 

le pare-feu est celui du « Java Card Runtime Environment » (JCRE) ; 
les donnees declarees comme partageables (et done sensibles) sont les 
objets qui sont instances de classes qui implementent I'interface 
«javacard.framework.Shareable » ainsi que, eventuellement, les objets a 
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usage public du systeme : tableaux globaux (« global aixays ») et objets 
points d'entree du JCRE (« JCRE Entry Point Objects »). 

8. Precede selon la revendication 7, 
5 caracterise en ce que le syst6me memorise dans les ensembles de references ' 
licites sensibles associes a un « package » toutes les references qui 
apparaissent dans les cas suivants : 

- la reception d'arguments de type « javacard.framework.Shareable » 
lorsqu'ime methode dudit package est appelee pai- un autre « package » ou 

10 par le systdme, 

- la valeur de retour de type « javacard.framework.Shareable » lorsque ledit 
« package » appelle une methode d'un autre « package » ou du systeme (y 
compris la methode « getAppletShareablelnterfaceObject » du package 
« javacard.frameworkJCSystem »), 

15 - la lecture d'un champ statique public de type 
« javacard.framework.Shareable » dans un autre package ou dans le 
systeme, 

- le rattrapage d'un objet instance d'une classe provenant (heritant) de 
«java.lang.Throwable» et implementant «javacard.framework.Shareable». 

20 

9. Precede selon I'une des revendications 1 et 4, 
caracterisd en ce que I'ensemble des references licites (ou licites sensibles) 
m^morisees est represente par une table. 

2^ 10- Procede selon Tune des revendications 1 et 4, 

caracterise en ce que I'ensemble des references licites (ou licites sensibles) 
m6moris6es est vide, grace a un ramasse-miettes, eventuellement conser%'atif, 
des references devenues inactives. 
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1 1 . Precede selon Tune des revendications 1 et 4, 
caracterise en ce que : 

- les r6f6rences sont repr6sen.t6es dans le systeme par des « handles » et des 
tables de pointeurs (on de references), 

certaines desdites tables sont eventuellement reservees aux references 
licites (ou licites sensibles), 

- les ensembles de references licites (ou licites sensibles) memorisees sont 
repr^sentes par des vecteurs (ou matrices) de bits assocife a certaines des 
tables de pointeurs (ou de r6f6rences), ou un bit a un index donn6 
repr^sente la presence ou I'absence de la reference correspondante dans 
lesdits ensembles, 

lesdits vecteurs de bits sont eventuellement creux et representes a I'aide 
d'une sequence d'indices ou de longueurs correspondant aux etendues de 
bits positionnes de la mgme maniere. 
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Cet imprim6 est & remplir lisiblement ^ I'encre noire 
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Vos references pour ce dossier (facultatij) 


TRUSB0023 


N*" D'ENREGISTRE^ErST NATIOriAL 


03 15545 du 30.12.2003 



TITRE DE L'li^lfEIMTIOI'l (200 earsctdres ou Qsi>sca& maximum) 

CONTROLE D'ACCES AUX DONNEES PAR VERIFICATION DYNAMIQUE DES REFERENCES LICITES. 



LE(S) DEiimDEUe^(S} : 

CABINET MOUTARD - 35, rue de la Paroisse - 78000 VERSAILLES - agissant en qualite de mandataire aupr^s de : 

TRUSTED LOGIC (S.A,) 
5, rue du BaHliage 
78000 VERSAILLES 



H Norn 


LEROY 


Prenoms 


Xavier | 


Adresse 


Rue 


37, boulevard Saint Antoine j 


Code postal et ville 


17 iSiOiOiOl VERSAILLES 


Societe d'appartenance (facultatij) 




0 Nom 


HAMEAU j 


Prenoms 


Patrice | 


Adresse 


Rue 


18, rue de Belie-Feuille | 


Code postal et ville 


19 i2 J 1 lO lO 1 BOULOGNE BILLANCOURT j 


Societe d'appartenance (facultatij) 




^ Nom 


REGNAULT j 


Prenoms 


Nicolas 1 


Adresse 


Rue 


66, rue Bayen { 


Code postal et ville 


17 tSiOil i7f PARIS 1 


Societe d'appartenance (facultatij) 




S'il y a plus de trois inventeurs, utilisez plusieurs formuiaires. Indiquez en haut a droite le fV" de la page suhfi du nombre de pages, f 
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m (DES) 0Er^AnDEUR(S) { 
OU DU ^ANDATArRE | 
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I Vqs references pom ce dossier (facultatif) 



TRUSBQ023 



03 15545 du 30.12.2003 



nTRE DE L^mVENTIOI^ (200 caractSres ou espsces maidmum) 

CONTROLE D'ACCES AUX DONNEES PAR VERIFf CATION DYNAMIQUE DES REFERENCES LICITES. 



LE{S) DE^AI^DEUg^(S) : '~ ^ — 

?rSLTeLTSg^^^ '""^ ^^'"^^^^ " ^^^^^ VERSAILLES < agfssant en qualite de mandataire aupres de ; 
5, rue du Bailljage 
78000 VERSAILLES 



Nom 



MARLET 



Prenoms 



Adresse 



Renaud 



Rue 



109 Avenue du Maine 



Code postal et ville 



Societe d'appartenance (facultatif) 



i7i5i0i1i4l PARIS 



Adresse 



Rue 



Code postal et ville 



Societe d'appartenance (fac ultatif) 
Nom 



I ' ' ■ ' i 



Prenoms 



Adresse 



Rue 



Code postal et ville 



Societe d'appartenance (faculta tif) 

S1I y a plus de trois inventeurs, utilises piusieurs formulaires. Indiquez en hau t a dmite le de la page suivi du nombre de 

DATE ET SIGnATURE(S) ' ~" 

DU (DES) DE^AnDEUR(S) 
OU DU MANDATAIRE 
(Nom et quality du signataire) 



31 decembre 2003 

A. de Saint Palais - No 94-0306 




La loi n°78-17 du 6 janvier 1978 relative a I'informatique, aux fichiers et aux libertes s'applique aux reponses faites k ce fonnubirp 
Elle garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de ^wT 
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